1. The Field of the Invention
The present invention generally relates to network description language contracts, e.g., Web Services Description Language (WSDL). More particularly, the present invention provides for extending such Network Protocol Description Languages by enabling each message within the same contract to be bound to a plurality of different binding mechanisms.
2. Background and Related Art
Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, database management, etc.) that prior to the advent of computer systems were performed manually. More recently, computer systems have been coupled to one another to form computer networks over which the computer systems can communicate electronically to share data. Web Services has been a driving force in advancing such communications between computer systems and is turning the way we build and use software inside-out.
Web Services let applications share data, and—more powerfully—invoke capabilities from other applications without regard to how those applications were built, what operating system or platform they run on, and what devices are used to access them. Web Services are invoked over the Internet by means of industry-standard protocols including SOAP (Simple Open Access Protocol), XML (extensible Markup Language), UDDI (Universal Description Discovery Integration), WSDL (Web Service Description Language), etc. Although Web Services remain independent of each other, they can loosely link themselves into a collaborating group that performs a particular task.
Often, electronic communication on a Web Service network includes a client computer system (hereafter referred to as a “client”) requesting access to a network service (e.g., Web Services) at a server computer system (hereinafter referred to as a “service”). Accordingly, the client sends a request to the service for particular access to its system resources, wherein if the client is authorized and validated, the service responds with a response message providing the desired information. Of course, other messaging patterns between client and service are available and include simple singleton messages as well as more sophisticated multi-message exchanges like, e.g., notifications, solicit-response, pub-sub patterns, polling, kick-push, queuing and others. Further, these types of communication are governed by various requirements and capabilities defined by both the client and the service in contracts for distributed systems (e.g., Web Services).
A contract is an expression of visible aspects of a service behavior. A contract is represented by a mixture of machine-readable languages and human language. Besides the obvious opportunity for additional precision, machine-readable languages enable tooling to construct partial service implementations, automate service deployment, audit/validate messages exchanged, manage services, and enable a host of other network-related functions. Due, however, to limitations in the expressive power of machine-readable languages, human languages remain an important component of contracts—principally to describe message and message exchange pattern semantics.
Network Protocol Description Languages (e.g., WSDL) provide an overall wrapper or specification for describing contracts (e.g., WS contracts) in a common or standard language. Such specifications make it easy for developers and developer tools to create and interpret contracts. Although such Network Protocol Description Languages (hereinafter referred to as “NPDL”) have extensive tooling suites, which in large part accounts for their popularity, there are currently several shortcomings and downfalls to such specifications. For example, current Network Protocol Description Languages bind a contract to a single protocol or binding mechanism which describes how to encapsulate or format the message (e.g., SOAP envelope) and what transport to use for exchanging the message with a service (e.g., HTTP (HyperText Transport Protocol), FTP (File Transfer Protocol), SMTP (Simple Message Transfer Protocol), TCP (Transmission Control Protocol), UDP (User Datagram Protocol), SMS (Short Message Service), SNA (Systems Network Architecture), GPRS (General Packet Radio Service), etc.).
Although some NPDLs allow for multiple bindings for a single contract, they do not allow for multiple binding mechanisms for the same binding, nor do they allow for different binding mechanisms for individual messages within the same contract. Accordingly, once a binding is chosen for a contract, each message defined by that contract is bound to the same binding mechanism described within the chosen binding. This unnecessary constraint on contracts limits the type of interactions for the message exchange patterns (MEPs) between a client and a service, and does not take full advantage of the unique characteristics provided by different binding mechanisms (i.e., different message formatting and/or different transports).
In addition, this model of binding a contract to a single binding mechanism does not accurately reflect the state of messaging systems, wherein one message in an exchange is carried over one transport whilst another message in the same exchange is carried over another. For example, multiple transports are commonly used because of differing network characteristics or requirements. Such is the case when a mobile service sends an SMS message to a mobile client, and in response the mobile client opens a TCP connection to the mobile service and sends a SOAP message back. Further, there are transports having unique capabilities that often times should be leveraged for different messages defined within the same contract. For instance, UDP is limited in size but allows for quick communication, whereas HTTP allows for larger data transfer and can go through a firewall one-way but not the other. Of course the many transports and/or binding mechanisms each have their own advantageous characteristics. Accordingly, one can easily imagine the desire for sending one or more messages within the same contract—and even for sending one or more messages within the same MEP—over separate transports to leverage their unique features.
Another drawback of current NPDLs is the rigid nature for addressing a service. Currently, addresses for a service are defined by standard URIs, e.g., a URL, which points to a specific web address. There are, however, instances where it may be desirable to express a service in a transport-neutral and self-contained way. For example, in the case of a typical URL, if the device doesn't support HTTP, then the device cannot get access without going through some other intermediary or proxy. This creates a problem for one of the fundamental purposes of Web Services, which is to provide services to a multitude of devices in an environment agnostic way.
Accordingly, there exists a need to be able to extend Network Protocol Description Languages to take full advantage of the various unique binding mechanisms available. Further, there is also a need for extending the addressing within a Network Protocol Description Language such that a service may be defined by URLs as well as a transport-neutral description of the service.